Conversation
There was a problem hiding this comment.
what is the second argument?
There was a problem hiding this comment.
thanks, good catch. This is outdated. Need to rewrite it 👍
There was a problem hiding this comment.
I have updated the description now.
|
These are small variant files produced with LocalApp code, right? Do we have an agreement on what small variant files we want to use when Dragen processes the data? Do you want to have separate functionality for handling those files or you want this code to be expanded so that it works for the Dragen data too? When I discussed with @danielvo about Dragen files containing small variants, he pointed to Results/**/*TMB_trace.tsv, which looks very useful but is not in vcf format. |
| @@ -0,0 +1,179 @@ | |||
| """ | |||
| This module contains the code for the `update_small_variant_vcf_list` command. | |||
| The command takes two arguments, `results_dir`, which is a string that specifies the directory where the results of the latest TSO500 run are stored. | |||
There was a problem hiding this comment.
What happens if there is a sample associated with a patient from the latest TSO500 run sequenced in one of the older runs (for example tumor DNA sample of patient A is sequenced in the latest run but normal DNA sample in one of the older runs)? Would it be useful for the older vcf file be added in the vcf list or not really?
There was a problem hiding this comment.
As far as I understood what this function does in TSOPPI, it updates the list according to the latest run so earlier run vcfs should be already be included.
| @@ -0,0 +1,179 @@ | |||
| """ | |||
| This module contains the code for the `update_small_variant_vcf_list` command. | |||
| The command takes two arguments, `results_dir`, which is a string that specifies the directory where the results of the latest TSO500 run are stored. | |||
There was a problem hiding this comment.
Should this functionality be used by other modules developed by other people - except for cli? If so, it would be great to have that summed up somewhere so that people are aware and can easily use this - probably your code using the functionality somewhere else will be enough..
There was a problem hiding this comment.
do you mean like a package on its own? Or do you mean within tsoppy itself? For the second case, I thought that any functions that we identify to be useful for other subpackages/modules we would move to a "common" subpackage. For the first case, I am not sure how relevant this might be but we can look into it if need arises.
|
Overall, it looks great and reads well! Surely will be useful part of the code. |
very good point, we agreed on collecting the necessary information to cover all possible input. The issue may serve as a reminder #8 |
2 participants
Hey guys!
This is my attempt at implementing the updating of the small variant vcf list. I have used the code we run at HUS, which is reflected in this nextflow process, as a base.
I have defined classes for the vcf list and the different vcf files to be able to write methods and gather all input values in one place. Also I wanted to create a clean interface towards the cli. Logging is handled by the logger defined in the cli module. Testing is done with table-driven tests, meaning we have different test cases for each function and collect them in a list of objects which we loop over. This makes things DRYer and provides a better overview of what is tested.
Please ask and comment so we can figure out if this is a good way to handle things☺️